Network tunnels are used to aggregate packet traffic between two network devices and can facilitate features such as private addressing, traffic engineering, communication of common properties of tunneled traffic, and aggregation of multiple flows over a single secure connection. Private addressing involves encapsulating private addresses with the packets being conveyed over the tunnel. Traffic engineering involves encapsulating addressing, which describes a particular path within the network, with a packet. The encapsulated addressing causes the packet to be forwarded along that path, independent of any addressing contained within the packet itself. By aggregating multiple flows into a single network tunnel over a secure connection, the aggregated flows can be protected (with respect to confidentiality, integrity and authentication) without having to establish a secure connection on a per flow basis.
Implementing a network tunnel typically involves encapsulating packets to be conveyed via the tunnel. These packets are encapsulated with a tunnel-specific header appropriate to the particular tunneling protocol being used. Examples of tunneling protocols include GRE (Generic Routing Encapsulation), MPLS (Multiprotocol Label Switching), and L2TP (Layer 2 Tunneling Protocol).
Traffic conveyed via network tunnels often experiences reduced performance relative to the performance of traffic that is not conveyed via a network tunnel. In particular, tunneled traffic may experience a higher loss rate than non-tunneled traffic. This higher loss rate arises when a tunnel, which appears as a single flow even though the tunnel actually aggregates multiple flows, experiences packet drop due to mechanisms such as RED (Random Early Detection), WRED (Weighted Random Early Detection), and DBL (Dynamic Buffer Limiting). These mechanisms cause packets to be dropped within a particular flow in order to signal that the flow should reduce its rate. These mechanisms signal rate reduction to individual flows instead of to the tunnel in which several individual flows are being aggregated. Furthermore, these packet drop mechanisms do not differentiate between the individual flows being aggregated within a tunnel. Accordingly, a packet selected to be dropped within the tunnel may be part of a flow that is not actually a significant portion of the tunnel's traffic. Thus, the use of such packet-drop mechanisms may cause tunneled flows that are not significant contributors to congestion to experience packet drop, leading to those flows reducing their rates, even though they are not actually large contributors to the congestion. The tunneled flows that are significant contributors to congestion may escape their share of packet drop, and as a result, these flows will not reduce their rates by an appropriate amount needed to actually reduce the congestion. Thus, the flow control provided by packet drop mechanisms may not be effective in reducing congestion when applied to a network tunnel.
Additionally, tunneled packets are often more prone to being dropped than non-tunneled packets because packets exiting a tunnel can require more processing than non-tunneled packets. This extra processing is due to the need to process both the tunnel header as well as the inner header (the original packet header, before encapsulation for transmission via the tunnel) of the packet. Consequently, many network devices cannot implement wire-speed tunnel egress processing, introducing another source of random packet loss. Tunneled packets can also be more prone to drop because all the packets in a tunnel appear as a single flow in an intermediate router. For example, if 100 TCP flows are aggregated into a tunnel, a typically fair-queuing mechanism at a congested intermediate router would give the aggregated flows 1/100 of the bandwidth that would be allocated if the flows were not aggregated, causing dramatically higher drops.